Two other things:

1/ you very likely edited curl_arginfo.h manually, I would suggest to revert this change locally and using build/gen_stub.php instead, i.e. php build/gen_stub.php ext/curl/curl.stub.php.
2/ Someone will very likely ask you to add a test before committing your change (i.e. ext/curl/tests for how they are made).

1/ you very likely edited curl_arginfo.h manually, I would suggest to revert this change locally and using build/gen_stub.php instead, i.e. php build/gen_stub.php ext/curl/curl.stub.php.

done, thanks

The existence of two distinct options CURLOPT_INFILESIZE and CURLOPT_INFILESIZE_LARGE is mostly due to low-level C considerations and I'm wondering if this distinction is useful/necessary in PHP. Are there cases where using CURLOPT_INFILESIZE_LARGE instead of CURLOPT_INFILESIZE would not behave as expected? Otherwise, should we define CURLOPT_INFILESIZE to @cvalue CURLOPT_INFILESIZE_LARGE directly?

I cannot answer this question, but maybe @nicolas-grekas can, but in the linked PR, we need to behave differently yes

I'm seeing just now that we already expose other _LARGE constants, so my suggestion would create inconsistencies. Therefore it's probably better to just add CURLOPT_INFILESIZE_LARGE as you are suggesting.

FWIW: The title of the PR typoed the name of the constant, the same issue also exists in the commit message, so probably be careful when merging this.

Hi @TimWolla can you explain? I can't see the typo

he meant this

Add \CURLOPT_IN I FILESIZE_LARGE
...

you can amend this commit at some point, or the committer will take care of it no worries :)

Will do

I don't think a test actually sending data using CURLOPT_INFILESIZE_LARGE makes much sense, but a test verifying the interoperability with CURLOPT_INFILESIZE may be reasonable. Does either affect the other (setopt vs getopt)? In case of using both, which takes preference – always the latter? Or does libcurl reject setting both options?

Please someone take over this PR if needed, I am not into C language and don't know how to test this @cmb69.

Thanks

Hi @OskarStark,
Thank you for the PR, and apologies for taking a loong time to review this.

The changes from the PR looks good to me. We can't merge this right now, because by the time you submitted the PR and now, the curl_arginfo.h file has changed, so merge conflicts. You can easily fix this by running php build/gen_stub.php while resolving the conflicts.

I have a PR against my php-src fork at Ayesh#28. Do you want to perhaps cherry-pick the commits there adding the tests and the UPGRADING entry?

Otherwise, I will come back to this in a few days and fix conflicts and merge this.

Thank you.

We can't merge this right now, because by the time you submitted the PR and now, the curl_arginfo.h file has changed, so merge conflicts. You can easily fix this by running php build/gen_stub.php while resolving the conflicts.

I rebased and regenerated the stubs.

I would be grateful if you could add the tests while merging, thanks

I don't think a test actually sending data using CURLOPT_INFILESIZE_LARGE makes much sense, but a test verifying the interoperability with CURLOPT_INFILESIZE may be reasonable. Does either affect the other (setopt vs getopt)? In case of using both, which takes preference – always the latter? Or does libcurl reject setting both options?

Spot-on :)

CURLOPT_INFILESIZE and CURLOPT_INFILESIZE_LARGE seem to be nicely compatible. It accepts CURLOPT_INFILESIZE to set a file size, and CURLOPT_INFILESIZE_LARGE can unset or overwrite it. So replacing existing PHP code with CURLOPT_INFILESIZE_LARGE is safe too.

I added a test with Caddy to print the incoming Content-length header. The tests check whether the header is present, but not really upload a file 2 > GB.

Many thanks for the support on this PR 🎉

Thank you.

We have quite a few Curl options missing in ext-curl. You can see them by running php ext/curl/sync-constants.php | grep CURLOPT_. If there are any options that Symfony HTTP Client could make good use, I think we can try and add them to ext-curl.

Good to know, thanks.

Right now I would say only add them when needed. WDYT @nicolas-grekas ?